The bug

The dep_gen DFX collector intermittently emits an empty deps.json:

AssertionError: deps.json missing expected edges: {(0, 4294967297), ...} (got set())

got set() — no edges at all, rather than wrong edges. The records are never
recorded, not buffered-and-unread and not dropped at emit.

dep_gen_aicpu_init() resolves the collector's buffer state and pops its first
buffer, and it ran from the scheduler cold path after the AICore handshake,
next to pmu_aicpu_init(). pmu belongs there — it needs the physical_core_ids_
the handshake produces. dep_gen needs nothing from it: init only reads
dep_gen_data_base, which kernel.cpp publishes before aicpu_execute() even
starts.

The orchestrator, meanwhile, deliberately skips that handshake
(aicpu_executor.cpp):

if (decouple_orch && is_orchestrator) {
    return 0;  // do NOT touch the handshake or hs_arrived_ barrier
}

so it goes straight to building the graph while the schedulers are still
handshaking cores. Every submit_task in that window reaches
dep_gen_aicpu_record_submit() with s_dep_gen_state still null and is dropped.

Instrumented device log, same binary, same card, only the width changed:

block_dim=3   PASS  dep_gen_aicpu_flush: pre_init_misses=0 init_calls=1 state=0x12c0c00e8440
block_dim=24  FAIL  dep_gen_aicpu_flush: pre_init_misses=5 init_calls=0 state=(nil)
                    dep_gen_aicpu_init:  entering        <-- after the flush

It is a race, not a capacity limit

Handshake wall time scales with core count, so the wider the device the more
often the orchestrator wins:

| block_dim | 2 | 3 | 4 | 6 | 8 | 12 | 20 | 24 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| pass rate | 2/2 | 5/5 | 2/2 | 1/2 | 3/4 | 0/5 | 1/5 | 1/5 |

There is no threshold and no 21/22 cliff — I looked for one, since #1477 had
just fixed a 21-cluster bound in CoreTracker, and this is not that. The
intermediate runs are the giveaway: several failed with tasks[] missing expected ids: {0}, i.e. the graph captured except its very first submit. No
sizing or indexing bug loses exactly the first record and keeps the rest.

This already reaches CI on main. The CI runner loses the race even at
block_dim: 3 — st-onboard-a2a3 on #1478, which does not touch block_dim at
all, fails with exactly this assertion, and main's own history has an
st-onboard-a2a3 failure among recent runs.

Why only dep_gen

pmu / args_dump / l2_swimlane are per-core subsystems whose producers are
downstream of the same handshake that gates their init, so they cannot race it.
scope_stats is orchestrator-side like dep_gen, but resolves its pointers inside
set_platform_scope_stats_base() — before aicpu_execute() — and pops its
buffer lazily. dep_gen was the only orchestrator-side subsystem with an eager
init parked behind the handshake. I ran all five per-feature smokes at full
width: only dep_gen failed.

The fix

Initialise dep_gen on the thread that feeds it, immediately before the existing
set_orch_thread_idx() and before orch_func_ runs. There is then nothing left
to order it against.

Both cold-path call sites go, not just one: the free_queue is SPSC and the
orchestrator must be its only device-side consumer. a5 carried the identical
arrangement and is fixed with it.

The silence

The failure surfaced as an empty file rather than an error because the early
return skipped the accounting one line below it — the line whose comment reads
"Account every attempted record so total == collected + dropped on host". The
host's reconcile_counters() saw 0/0/0, called that consistent, and wrote
{"tasks":[],"tensors":[],"edges":[]}.

A pre-init record cannot be accounted — the counter lives in the BufferState
that is still null — so it now reports itself once instead. Once, because
record_submit is a per-task path and the AICPU log is not free
(.claude/rules/codestyle.md §7).

Verification

Not run on this branch: the full onboard a2a3 suite and the other four DFX
smokes. The dep_gen smoke is the one that reproduces this, and it was run across
eight widths; the rest is unverified here.

Follow-up, not fixed here

host_build_graph calls dep_gen_aicpu_init()
(src/a2a3/runtime/host_build_graph/runtime/scheduler/scheduler_cold_path.cpp:899)
but never calls dep_gen_aicpu_set_orch_thread_idx() or ..._flush(), so
s_orch_thread_idx stays -1 and an enqueue_ready would index queues[-1].
Unreachable today — hbg has no dep_gen consumer path — but it is a separate bug
and wants its own change. Filing an issue.

Unblocks #1478 and #1309, both of which are red on this assertion.